1. Field of the Invention
The present invention relates generally to network-based graphical user interfaces. More particularly, the present invention relates to systems and methods for enhancing the portability and maintainability of an object oriented interface among multiple platforms such that the interface can, for example, be used with a client/server environment that integrates any of a variety of different hardware and/or software platforms.
2. State of the Art
Known graphical user interfaces provide application developers with an application program interface (API) that includes a collection of objects, such as scroll bars, push buttons, text entry fields and so forth. An object oriented graphical user interface (GUI) typically includes a hierarchical collection of these objects in a "toolkit".
The behavior of a graphical user interface within a system is defined by interactions between the objects in the client of a client/server environment and the window-based system server. A paradigm used to represent defined interactions between the objects is often referred to as a "model-view-controller" (MVC) paradigm of object interaction. The model-view-controller paradigm formally defines the manner by which changes in state occur within at least part of the system (e.g., a timer of the system), and how those changes are to be communicated to, or reflected in, other parts of the system that have established an interest in observing such state changes (such as a displayed clock). The controller can be considered a set of rules which define how state changes implemented in response to a model will affect a view. Using the model-view-controller paradigm, the toolkit can be considered a hierarchical collection of models, views and controllers that implement the graphical user interface.
FIG. 1A illustrates an abstract representation of interaction among a model 102, a view 104 and a controller 106, wherein the model can be considered stored data, and the controller can be considered the rules by which the model and the view interact. Arrows 108 in FIG. 1A depict the most general model-view-controller paradigm wherein state changes can flow in both directions.
Referring to FIG. 1B those skilled in the art will appreciate that the distinctions between the model, the view and the controller often overlap in implementation even though the model, the view and the controller are conceptually distinct. For example, a scroll bar object 112 of an object oriented graphical user interface can represent both a controller as well as a view. The scroll bar of FIG. 1B is a view when, for example, it graphically represents the percentage of a text file 114 which has been, or is being, displayed in a text view 116 (i.e., anywhere from zero percent to 100 percent). The scroll bar responds to a series of control events generated by a mouse to display the current location of the scroll bar on a monitor. As referenced herein, an "event" represents information of a state change which is particular to implementation on one window-based platform and generic in concept across window-based platforms between which portability is desired.
In this example, the scroll bar 112 can also be a controller which is used to initiate, or control, the updating of a display of text from the text file 114 in response to movements of the mouse. That is, by "clicking" on the scroll bar and moving its image 112 vertically, the scroll bar serves as a controller which generates a stream of notifications that are sent to and used by the view 116 to continuously redraw the scroll bar as it is moved up and down the display, thereby changing the presentation of the scroll bar, and thus the contents of file 114 which are displayed. In the FIG. 1B example, the model (i.e., the text file 114) defines how user activation of the mouse will affect a displayed view of the scroll bar and thus the text file.
In a typical window-based system, such as the UNIX based X-Window System.TM. from the Massachusetts Institute of Technology, state changes within the system are communicated to graphical user interface clients via "events", in a manner similar to that described above with respect to the model-view-controller paradigm. When a window-based system is associated with an object oriented graphical user interface toolkit, the toolkit maps state changes in the window-based system, reported via window system events, onto an object oriented model-view-controller. The window-based system event results in a method invocation on an object of the graphical user interface to notify it of the state change.
The definition of the relationships between models, views, and controllers is established by implementation-specific definitions of object "classes". Although the relationships between particular instances of models, views and controllers can be dynamically specified during the lifetime of an application, these relationships are not alterable at the time of execution of a client-side application except through assignment between instances of particular implementations of the models and views. This is the case, for example, where object oriented systems are implemented in programming languages such as C++.
Because the interactions between objects are defined by a model-view-controller developed as a platform specific implementation for use with a specific window-based environment, the toolkit cannot be readily ported from one window-based platform to another. That is, an "event" found in a native window-based platform for which a toolkit was implemented can differ significantly in implementation from another window-based platform to which the toolkit is to be ported. Further, native implementations are simply not designed with portability to other environments as a goal, such that platform dependencies are not typically localized or abstracted within the native platform. An "event" defined for one platform is usually different in implementation with respect to other platforms in terms of the information which is provided (i.e., different semantics), as well as the format with which any such information is provided (i.e., different syntax). The amount of computer code which must be revised to use a toolkit defined for one window-based platform with another window-based platform is therefore excessive and impractical. As such, significant problems exist in porting an object oriented graphical user interface from a native window-based platform to another window-based platform (e.g., such as porting from the NeXTSTEP environment of NeXT Computer Company onto another window-based platform such as the X-Window Systems.TM.).
Accordingly, it would be desirable to develop a method by which platform dependencies can be localized and abstracted for use with an object oriented graphical user interface, wherein object interactions are defined with respect to an abstract model-view-controller. For example, it would be desirable to abstract the events received from a window-based system so that the primary portions of code used to represent a toolkit of an object oriented graphical user interface can remain unchanged, and therefore be easily ported to any of a variety of window-based platforms.